1. Field of the Invention
The present invention relates the IP Multimedia Subsystem (IMS) and more specifically to systems and methods of managing user registrations and portability of services within these systems.
2. Introduction
The IMS (IP Multimedia Subsystem) is technology that merges the internet with the cellular world. It makes internet technology such as the web, email, instant messaging, user presence, video conferencing and so forth available in nearly any location. The IMS is a key element in third generation (3G) architecture that makes it possible to provide ubiquitous sailor access to all services that the internet provides. For example, it enables one to access their favorite web pages, read their email, watch a movie or take part in the video conference wherever one is by simply using a mobile device and accessing the desired services. There are several references with which it is assumed that the reader is familiar as background for the present disclosure related to the IMS. Accordingly, further details provided herein may be found in the 3G IP Multimedia Subsystem (IMS), Merging the Internet and Cellular Worlds, by Gonzalo Camarillo and Miguel A. Garcia-Martin, John Wiley and Sons Ltd., 2006 and the IMS, IP Multimedia Concepts and Services, by Poikselka, Mayer, Khaitabil and Niemi, John Wiley and Sons Ltd., 2006. A brief introduction shall be provided while further details may be found in these references.
The IMS aims to combine the latest trends in packet switch technology and circuit switch technology to make a mobile internet available. It also aims to create a common platform to develop various multimedia services and to create a mechanism to boost margins for service providers due to extra usage of mobile packet switch networks. There are various protocols used in the IMS which include the session control protocol, and a session initiation protocol (SIP) as well as other protocols known to those of skill in the art that are utilized for providing the multimedia services. The IMS architecture is a collection of functions linked by standardized interfaces. Most venders follow the IMS architecture closely and implement each function in a single node although other nodes may be used.
FIG. 1 illustrates the basic IMS architecture 100. This is the architecture as standardized by 3GPP, which is the third generation partnership project that was charted to develop specifications for the evolution of GSM, which is the global system for mobile communication which is one of the most popular standards for mobile phones. FIG. 1 illustrates most of the signaling interfaces using the IMS which are typically referred to by a two or three letter code. This is only a partial list of the potential interfaces. IMS mobile terminal 140 communicates with a packet network 136 such as the GPRS network or other networks, through a radio link 138. The IMS also supports other types of devices and accesses as well. Personal digital assistants (PDAs) and computers 102 are examples of devices that can connect to the IMS through alternative accesses such as the public Internet, WLAN or ADSL 104. Other nodes are also shown as part of the IP multimedia core network subsystem. These nodes include one or more user databases typically called home subscriber services (HSSs) 120 and subscriber location functions (SLFs) 122. One or more SIP servers are shown which are collectively known as call/session control functions (CSCFs) 116, 118. One or more application servers are shown such as a SIP application server 108. One or more media resource functions (MRFs) are shown 126, 128 which may further be divided into media resource function controllers (MRFCs) 126 and media resource function processors (MRFPs) 128. There may be one or more breakout gateway control functions (BGCFs) 124 which is essentially an SIP server that includes routing functionality based on telephone numbers. The BGCF 124 is typically only used in sessions that are initiated in an IMS terminal and addressed to a user in a circuit switch network such as a PSTN or the PLMN. The main functionality of the BGCF 124 is to select an appropriate network for interworking with the circuit-switch domain is to occur or to select an appropriate PSTN/CS (circuit-switch) gateway, if interworking it so occur in the same network where the BGCF is located.
Also shown in FIG. 1 is one or more PSTN gateways, each one decomposed into a signaling gateway press (SGW) 130, a media gateway controller function (MGCF) 132 and a media gateway (MGW) 134. The HSS 120 is a central repository for user-related information. It is understood that the HSS 120 is an evolution of the home location register (HLR) which is a GSM node. The HSS 120 contains all the user related subscription data requires to handle multimedia sessions. The data can include among other items, location information, security information, authorization information, authentication information, user profile information, which may include the services that the user has subscribed to and the serving-CSCF (S-CSCF) 116 allocated to the user. The CSCFs which are typically SIP servers, are important nodes in the IMS. The CSCF processes SIP signaling in the IMS. Shown in FIG. 1 are three types of CSCFs that depend on the functionality they provide. The proxy-CSCF (P-CSCF) 106A is typically a first point of contact in a signaling plane between the IMS terminal 140, 102 and the IMS network 100. From the point of view of the SIP protocol, the P-CSCF 106A, 106B acts as an inbound/outbound SIP proxy server. This means that all requests initiated by the IMS terminal 102, 140 or destined for the IMS terminal 102, 140 traverse the P-CSCF 106A, 106B. The P-CSCF forwards SIP requests and responses to the appropriate direction, such as toward the IMS terminal 102, 140 or toward the IMS network 100. The P-CSCF 106A, 106B is allocated to the IMS terminal during IMS registration and does not change for the duration of the registration which typically means that the IMS terminal communicates with a single P-CSCF during the registration. The P-CSCF includes several functions which may be related to security. For example, it may establish a number of IP SEC security associations toward the IMS terminal 102, 140. These IP SEC security associations offer integration protection which is the ability to detect whether the contents of the message have been changed since its creation. Once the P-CSCF authenticates the user, the P-CSCF asserts the identity of the user to the rest of the nodes in the network. In this way, other nodes do not need to further authenticate the user because they trust the P-CSCF and the rest of the nodes in the network user's identity have a number of purposes such as providing personalized services and generating account records. The P-CSCF also verifies the correctness SIP request sent by the IMS terminal 102, 140. This verification keeps the IMS terminals from creating SIP requests that are not built according to the SIP rules. Each P-CSCF serves a number of IMS terminals depending on the capacity of the node. Further details regarding the P-CSCF are known to those of skill in the art.
Next, an interrogating CSCF (I-CSCF) 118 may also be used in the network 100. This is a SIP proxy located typically at the edge of an administrative domain. A serving-CSCF (S-CSCF) 116 is a central node of the signaling. This node is essentially a SIP server but performs session control as well. In addition to SIP server functionality, the S-CSCF 116 also acts as a SIP registrar. This means that it maintains a binding between the user location, which is the IP address of the terminal the user is logged on, and the user's SIP address of record which is also known as a public user identity (PUID). The S-CSCF 116 also implements a diameter interface to the HSS 120 for the purpose of downloading authentication vectors of the user that trying to access the IMS from HSS. The S-CSCF uses these vectors to authenticate the user. The S-CSCF may download a user profile from the HSS 120. The user profile includes the service profile and a set of triggers that may cause a SIP message to be routed through one or more application servers. The interface may also inform the HSS 120 that this is the S-CSCF 116 allocated to the user for the duration of the registration.
The SIP-AS 108 is a native application server that hosts and executes IP multimedia services based on SIP. The open service access-service capability server (OSA-SCS) 110 is an application server that provides an interface to the OSA framework application server. It inherits all the OSA capabilities and especially the capability to access the IMS securely from external network. The node acts as an application server on one side and is the interface between the OSA application server and the OSA application programming interface on the other side. The IP multimedia services switching function (IM-SSF) 112 is a specialized application server that allows the system to use customized applications for mobile network enhanced logic (CAMEL) services that were developed for GSM in the IMS. The details on these various nodes are known to those of skill in the art.
The signaling gateway (SGW) 130 interfaces the signaling plane of the CS network, such as the PSTN. The SGW 130 performs lower layer protocol conversion such as being responsible for replacing the lower MTP transport with a stream control transmission protocol (SCTP) over IP. The media gateway control function (MGCF) 132 is a central node of the PSTN/SC gateway and implements a state machine that does protocol conversion and maps SIP to either ISUP over IP or VICC over IP which are control protocols in circuit switch networks. The media gateway (MGW) 134 interfaces the media plane of the PSTN or CS network. On the one side, the MGW 134 is able to send and receive IMS media over the real time protocol (RTP). On the other side, the MGW 134 uses one or more pulse code modulation time slots to connect to the CS network. The MGW 134 may also perform transcoding when the IMS terminal 140, 102 does not support the codec used on the CSI.
Many other basic aspects of the IMS architecture may be found in Camarillo et al., Chapter 3. With this basic introduction in mind, we now focus on the IMS registration process which includes a number of deficiencies.
Prior to IMS registration, the user equipment (UE) 102 must discover the IMS entity to which it will send a register request. This concept is called a proxy-call session control function. This is called P-CSCF discovery and is described in Section 3.8 of Poikselka et al. In addition, before the registration process, the UE 102 needs to fetch user identities from identity modules. An S-CSCF will be assigned, authentication will be formed and its corresponding security associations will be established. A user profile will be downloaded from the HSS 120 to the assigned S-CSCF 116 and SIP compression will be initialized and implicitly registered PUIDs will be delivered. The IMS registration process contains basically two phases. The first phase is shown in FIG. 2A which involves how the network challenges the UE 102. FIG. 2B illustrates the second phase which is how the UE 102 responds to the challenge and completes a registration.
First, as shown in FIG. 2A, the UE 102 sends a SIP register request to the discovered P-CSCF 106A. This request may contain an identity to be registered in a home domain name or an address of the interrogating-CSCF (I-CSCF) 118. The P-CSCF 106A processes the register request and uses the provided home domain name to resolve the IP address of the I-CSCF 118. The I-CSCF in turn will contact the HSS 120 to fetch the required capabilities for the S-CSCF 116 selection. After HSS 120 selects the S-CSCF 116, the I-CSCF 118 forwards the register request to the S-CSCF 116. The S-CSCF 116 realizes that the user is not authorized and therefore retrieves authentication data from the HSS 120 and challenges the user with a 401 unauthorized response.
Second, the UE 102 will calculate a response to the challenge and send another register request to the P-CSCF 106A. This is shown in FIG. 2B. Again, the P-CSCF 106A finds the I-CSCF 118, and in turn, finds the S-CSCF 116. The S-CSCF then checks the response and, if it is correct, downloads a user profile from the HSS 120 and accepts the registration with a 200 OK response. Once the UE 102 is successfully authorized, the UE is able to initiate and receive sessions. During the registration procedure, both the UE 102 and the P-CSCF 106A learn which S-CSCF 116 in the network will be serving the UE 102. Table 1 illustrates the information storage before, during and after the registration process.
TABLE 1Before During After NodeRegistrationRegistrationRegistrationUEP-CSCF P-CSCF P-CSCF address, address, homeaddress, homehomedomain name,domain name,domain name,credentials, credentials, public usercredentials, public useridentity (and implicitlypublic useridentity, registered public useridentity, private useridentities), private userprivate useridentity, identity, securityidentifysecurityassociation, serviceassociationroute information (S-CSCF)P-No state Initial network Final network entryCSCFinformationentrypoint (S-CSCF), UEpoint, address, registeredUE IP public user identityaddress,(and implicitlypublic and registered public userprivate useridentities), private userIDs, security ID, securityassociationassociation, address ofCDFI-HSS or HSS or SLF HSS or CSCFSLF entry, P-SLF addressaddressCSCF address, S-CSCFaddressS-HSS or HSS address/HSS address/CSCFSLF name, username,addressprofile (limited - user profile as per(limited -network as per scenario), proxynetworkaddress/name,scenario), proxypublic/private address/name,user ID,public/UE IP private user ID,addressUE IP addressHSSUser User profile, User profile, profile,S-CSCFS-CSCFS-CSCFselection selection selectionparameters,parameters,parametersvisited information aboutnetworkwhich user identitiesinformation if are registered, name ofuser isthe S-CSCF allocatedroamingto the user
It is the UE's 102 responsibility to keep its registration active by periodically refreshing its registration. If the UE 102 does not refresh its registration, then the S-CSCF 116 may silently remove the registration when the registration time lapses. When the UE 102 wants to de-register from the IMS, it sets a registration timer to 0 and sends a registered request. Poikselka et al. Sections 10.5 and 10.14, incorporated herein by reference as background material, provide further details regarding IMS registration and de-registration.
The basic IMS registration process is insufficient to meet customer needs in support of service mobility and a user-centered network. There are several aspects of the basic IMS approach that are problematic. First, all registrations and de-registrations must come from the contact address at which the PUID is being registered or de-registered. This can be problematic because the user may not have the device in question or a legacy device may not be able to originate the registration. Further, registrations may expire without intervention.
The use of the Private User Identify as part of the authentication process for registrations introduces difficulty in service mobility. The Private User Identify represents both the equipment and the user. This works well for single user devices such as cell phones, but creates unaddressed issues for shared devices and for users who want services on devices that they are using temporarily, such as hotel phones or visitors office phones. Further, there is no support for event-driven registration and de-registration except based on registration expiration. Yet another issue in the IMS registration process is that it assumes that all equipment will be capable of self-registration. For users that are mobile between devices, registrations and de-registrations will become common place.
Another problem arises when a customer decides that he or she wants to stop receiving calls from a device after having already left it. For example, a business women waiting for an important business call may leave children with a babysitter and go out for the evening. After she has left, while she may be able to register her business persona on her cell phone, she may not be able to de-register from the phone using the basic IMS registration approach which may still maintain the registration. This could result in a child or a babysitter answering an awaited call from a business associate.
Single-point management of registrations also would be difficult. While it would be possible to request a network service to give information on where a PUID was registered, the requirement that registration and de-registration be done from the device itself forces any registration manager to rely on accessing capabilities within the device to change registrations. Accordingly, what is needed in the art is an approved system and method of managing the registration process within an IMS context to enable improved user flexibility in receiving IMS services.